In order to provide connections between networks that are secure, leased lines are often used because they generally are not publicly accessible. However, leased lines tend to be expensive, and so there is an incentive to use public networks, such as the Internet, to create secure tunnels between remote private networks. However, public networks are inherently not secure. Therefore, various techniques and protocols must be used to ensure that communications sent over a public network are secure and that private networks connected to the public networks are secure from attacks.
Security, in this context, consists primarily of the following three concerns: If data is to be securely transported over a public network, such as the Internet, it must be protected against intentional or accidental modification. In addition, if privacy is a concern, the data must be encrypted to prevent eavesdropping by unauthorized eyes. Finally, the establishment of a secure connection must provide for some kind of guarantee regarding the identity of each participant in the exchange of data. These three concerns are referred to herein as “data integrity”, “confidentiality”, and “source authentication” (also referred to herein as simply “authentication”), respectively. Although there are network security considerations that are not discussed herein (e.g., non-repudiation), these three, and authentication in particular, are sufficient for describing the present invention.
A “tunnel” is a term sometimes used to denote a secure channel that is configured between two endpoints to enable information to be securely exchanged between the endpoints. An example of this usage is the tunnel mode of the Internet Security Protocol (IPSec) and the associated IPSec Encapsulating Security Payload (ESP) Protocol, which may be used to create a Virtual Private Network (VPN). Another related, but more general, use of the word “tunnel” is when an “inner” protocol packet is transported as the payload of another “outer” protocol packet. This encapsulation process is typically accomplished by attaching the outer protocol “header” to the inner packet, thus creating a new, larger packet. At the other end of the tunnel, a decapsulation process restores the original, inner payload packet. In principal, there is no limit to the number of times this tunneling process can be nested, since the packets of one tunnel can be encapsulated within another tunnel. As long as each nested tunnel header is decapsulated at its corresponding tunnel endpoint, the original packet can be successfully retrieved.
Each tunnel header provides information that is typically used to identify the type of tunnel with which it is associated, to authenticate the packet, and to perform other services. It should be noted that the network endpoints of the outer tunnel packets are not necessarily the same as the network endpoints of the inner payload packets, because both tunnel packets and payload packets may carry independent network addresses in their respective headers. Therefore, when a payload packet has been decapsulated at a tunnel endpoint, it might afterwards be forwarded to, for example, an ultimate destination by the tunnel endpoint device (e.g., a security gateway, or other tunnel endpoint device.)
The establishment of a tunnel generally involves performing processes that prevent unauthorized access to a network located at an endpoint of the tunnel. A tunnel can be as simple as a channel between two endpoints in which identity authentication is performed by the mutual exchange of shared secrets or passwords between these endpoints. In this simplified case, if the passwords are correct, the participants are assumed to be legitimate and are assumed to have agreed to exchange data.
Tunnel configurations can also be highly complex so that the level of security associated with transmitting information over the channel and gaining access to the networks through their respective endpoints is very good. Currently, various protocols exist that are intended to provide secure communication over public networks, such as, for example, the Internet Protocol Security (IPSec) protocol. IPSec is generally considered to be a standard protocol for communicating securely over the public Internet. IPSec provides layers of security via security policies and cryptographic algorithms.
Tunnel services are often provided by devices that also provide other services. “Routing” is a term usually employed to refer to the process of selecting the route for a network packet to take when traversing between two network endpoints. A router is a piece of equipment that, among other things, is involved in making these routing decisions. A router may also have features for establishing and managing authenticated tunnels, and for determining which routes within the trusted network are accessible to packets entering and leaving each tunnel. Existing VPN equipment was designed with the assumption that authenticated payload data may be trusted to provide its own routing information. This is because secure tunneling has been viewed primarily as an economical method for interconnecting networks that, although remote from each other, are part of the same trust domain.
These various protocols, including the IPSec protocol, typically communicate data in the form of packets that include header information used to identify and authenticate the originator of the packet. These packets also include a “payload”, which is the data to be transported, and which may include various unspecified types and formats of data. If a particular payload packet is an IP packet, it will include IP header information. However, while encapsulated within a tunnel packet, the IP header does not normally participate in network processes, other than in the context of “a passenger”. The additional IP header information is added to the payload packet as a result of IPSec ESP tunnel mode encapsulation and provides tunnel management information. This additional IP header information may be viewed as the “outside” of the tunnel, whereas the payload is considered to be “inside” the tunnel. Once a tunnel has been established and configured, end-to-end transfers of data may take place through the tunnel between the endpoints. Conceptually, a tunnel could be unidirectional, although they typically allow bi-directional transfer of packets.
Encryption and decryption techniques are often employed as part of the processing of data as it enters and exits a tunnel. This provides protection against the risk of eavesdropping by untrusted agents during data transit, which can occur when tunnels are created over public networks if such additional protection steps are not taken. However, if the transport network is private and trusted, or if there is no need to keep the data private, then the primary purpose for using a tunnel may only be authentication. Because the benefits of the present invention are associated primarily with the authentication process, the present invention is applicable to any tunnel method that involves authentication, whether or not encryption/decryption or other processes are also involved, as discussed below in the Detailed Description of the Invention.
When a tunnel is created, an important initial requirement is to create a Security Association (SA) that represents a “contract” between the participants. These SAs are used thereafter during the life of the tunnel to authenticate packets as having come from the original participants. In IPSec, each SA is unidirectional, so two SAs are required (inbound and outbound) to create a bi-directional tunnel. A tunnel endpoint is able to use the information contained in the SA to verify each inbound packet arriving through the established tunnel as having come from the other contracting SA party. An SA may be created with a finite lifetime, and if an SA expires, a new one must be established if communication is to continue through the tunnel.
The process of creating an SA necessarily involves the establishment of a private shared key, known only by the two tunnel endpoints. One example of a known method for establishing a shared key is commonly referred to in the art as the Diffie-Hellman key exchange. Because key exchange processes can be computationally expensive, there is an incentive to use a single SA for the authentication of many individual payload packets. After the secure exchange of a shared key, all payload packets transported through a tunnel can be efficiently authenticated by various methods based on the shared key by, for example, using Message Authentication Codes (MACs).
Throughout the remainder of this document, “authentication”, unless otherwise stated, is intended to denote the process of establishing confidence that a packet came from the same party that established the SA by which (using the shared key, and other information in the SA) the packet is to be cryptographically validated. It should be noted that, if appropriate care is taken to observe adequate security processes, then authentication may be viewed as a method of verifying the party from whom a packet came. The packet may be assumed to have come from a party to the password, private key, or other secret information that was required to create the SA. In this sense, an SA may be viewed as data that identifies the originator of the packet.
After the authentication phase, a tunnel is available for the exchange of data packets between the endpoints. A preparation process (encapsulation) is performed on packets as they enter a tunnel, and a verification process (decapsulation) occurs as the packets exit the tunnel. The preparation process adds authentication information to each payload packet, and the verification process removes the authentication information. The verification process confirms or rejects the authenticity of payload packets. This typically involves mathematical processes (e.g., hashing) designed to provide very high confidence as to the probable origin of the packet. In the best case, such processes are widely believed to provide a virtual guarantee of authenticity. If encryption or scrambling is also used to enhance privacy, an additional goal of decapsulation is to convert the packet back to the original unencrypted or unscrambled format (i.e., the form that it had before entering the tunnel). Once all necessary decapsulation processes have been completed, the authenticated packet is often classified thereafter as “trusted”, and, consequently, is merged in with other trusted network traffic.
The assumption that all incoming tunnel packets are equally trusted creates dependencies that complicate the network administration process. If additional security requirements exist, such as the need to restrict tunnel traffic to a subset of resources in the remote network, these requirements must be enforced by additional methods beyond the tunnel itself. The security of these additional methods rests on the reliability and accuracy of the contents of the payload packets, because this is normally the only information available after decapsulation. Decapsulation removes the information that was added during encapsulation. Using the IPSec ESP tunnel protocol as an example, when a payload packet arrives at a tunnel endpoint, the outer IP header, the ESP header, and the ESP trailer are removed. After successful packet authentication, this encapsulation information is deemed reliable, thereby establishing confidence as to the identity of the sender, as discussed previously. However, after discarding the encapsulation fields, the information in the payload packet itself is all that is available for subsequent security processes, and so the payload data must be verified for accuracy if the security rules (access and routing) of the remote network are to depend on it. This is because, although the tunnel authentication process validates the identity of the sender, it gives no direct assurance as to the reliability or accuracy of the payload data contained in the payload packets.
This means that a potential for “spoofing” (i.e., providing false packet information to subvert restrictions) exists with respect to the information (such as layer 3 addresses, port numbers and protocol numbers) embedded within the tunnel payload. A tunnel may provide authentication and data integrity, but it does not provide protection against false or unreliable information contained within the payload itself. Therefore, unless special processes are put in place to validate the information contained within the payload packets, there is nothing to prevent authenticated tunnel participants from using packet spoofing methods to gain access to resources within the remote network to which they have not been granted valid authorization.
To eliminate potential spoofing problems in this example situation, it would be necessary to analyze packets after they have exited a tunnel, and to determine which resources the author of the packet is allowed to access within the remote network. For example, a user may have permission to connect to a remote network over a VPN tunnel, but may only be allowed to access a limited set of selected services within the remote network. However, the VPN process itself is an “all-or-nothing” process, in the sense that packets are either totally accepted as authentic (and therefore deemed to be trusted), or are rejected in their entirety. Therefore, the additional information required to enforce additional access control restrictions would have to be derived by analyzing the contents of the trusted payload packets themselves.
Some existing VPN devices provide varying degrees of support for post-VPN analysis of packets (for example, in the form of access control lists). These types of post-VPN features provide a limited means for attempting to distinguish between valid and spoofed packets. Packet analysis rules that are sufficiently rigorous may be able to reject illegal or suspicious packets. Under some circumstances it may be possible to securely enforce all required additional access restrictions within the remote network. However, some negative consequences of having to rely on the analysis of payload data are:                the security of the resulting system depends on the adequacy of the analysis of the incoming payload packets;        the process of creating, verifying, testing, and maintaining payload analysis rules can be tedious, slow, error-prone, and expensive; and        the tunnel cannot safely be used to transport packets for which analysis mechanisms have not been established.        
The last restriction can be rather severe, because it forces a tradeoff between the costs of maintaining access rules, and the value of the various protocols allowed to pass through the tunnel. This tradeoff applies to any and all security processes that depend on information contained in the payload packets, because any such process requires rules that are based on the organization and interpretation of the data contained in the packets.
Routing or access control rules are typically based on various fields of a layer 3 packet header, and sometimes on payload data itself. One example of a routing rule would be a static routing table entry directing all packets outside a specified destination address range to a specific gateway address. An example of an access control list would be a rule that mandates that all traffic on a particular protocol port be rejected unless addressed to a limited range of web server addresses.
The process of selecting the destination of network frames and/or packets has historically been described using terminology that differs depending on the layer of the Open Systems Interconnect (OSI) model to which the frames and/or packets belong. Layer 2 decisions, although sometimes referred to as “layer 2 routing”, are more commonly referred to as “switching” decisions, whereas the Layer 3 decision process is most commonly referred to as “routing”. Ethernet frames, switch ports, and port-based VLANs all exist at Layer 2 of the OSI model, whereas IP packets correspond to layer 3 of the OSI model. One commonality between switching and routing is that they both correspond to a process of deciding the address of the next hop for a packet or frame, although each restricts itself to using address information at their respective OSI layers.
A limitation of existing network devices and techniques is that, although a tunnel itself may serve as a carrier for layer 3 packets (and may therefore be viewed as existing at layer 2), existing network devices have not made it possible to securely associate tunnel packets with layer 2 destinations, except through the use of a multi-step process that involves using the layer 3 information contained in the payload packet. For example, the process of routing all packets from tunnel A to a VLAN B could be accomplished by restricting the layer 3 addresses of all packets entering and leaving tunnel A, and then associating the same restricted layer 3 addresses to VLAN B (for routing purposes).